Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug Fix] retry_on handling and add support for lists in RetryPolicy #1753

Merged

Conversation

Etelis
Copy link
Contributor

@Etelis Etelis commented Sep 18, 2024

This PR addresses two issues in the run_with_retry function:

  • Exception Classes Misidentified as Callables:
    Issue: Exception classes are callable, leading callable(retry_policy.retry_on) to mistakenly treat them as callables for custom retry logic.

  • No Support for Lists in retry_on:
    Issue: retry_on accepted only exception classes, tuples, or callables, not lists of exceptions (as defined in the documentation)

Summary of Changes:

  • Modified retry_on type annotation to include List[Type[Exception]].
  • Updated run_with_retry to handle lists and tuples when checking exceptions.
  • Ensured exception classes are not incorrectly treated as callables.
  • Added a TypeError if retry_on is of an unsupported type.

Itay Etelis and others added 5 commits September 18, 2024 13:39
Previously, `retry_on` in `RetryPolicy` accepted only exception classes, tuples of exception classes, or callables.
Update the `retry_on` type annotation to include `List[Type[Exception]]`

Changes:
- Updated `retry_on` in `RetryPolicy` to accept `List[Type[Exception]]`.
- Correctly distinguish between exception classes, lists/tuples of exception classes, and callables.
- Add support for lists in `retry_on`, alongside tuples.
- Prevent exception classes from being incorrectly treated as callables.
- Raise a `TypeError` if `retry_on` is of an unsupported type.
@nfcampos
Copy link
Contributor

Thanks for this! Made a few updates, will merge it once CI finishes

@Etelis
Copy link
Contributor Author

Etelis commented Sep 18, 2024

Thank you.
Also, what are your thoughts on introducing type checking for the types.py file?
@nfcampos

@nfcampos
Copy link
Contributor

@Etelis in the past we faced some issues with getting mypy to behave with our codebase. I can try to see if mypy has improved since, but would probably be a fairly involved task

@nfcampos nfcampos merged commit d46fd25 into langchain-ai:main Sep 18, 2024
50 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants